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ABSTRACT 

This  paper  describes  a simulation  model  in  which  user  jobs  are 
synthesized  from  basic  building  blocks.  The  modelling  process  consists  of 
three  stages: 

translation  from  a user  view  of  data  and  processes  dependent  on  the 
data  base  management  system  (DMS)  into  a standard  form  consisting 
of  explicit  access  paths  over  logical  data  structures; 

translation  of  the  logical  structures  and  operations  into  block-oriented 
structures  and  operations  on  a virtual  machine;  and 

execution  of  a number  of  concurrent  jobs  on  a real  machine. 

This  paper  deals  only  with  the  last  two  stages.  Standard  forms  for  the  logical 

structures  and  operations  and  for  the  virtual  machine  are  described;  they  are 

as  free  as  possible  from  the  data  view  of  the  particular  DMS.  We  describe 

a generalized  modelling  framework,  which  becomes  a model  of  a particular 

DMS  when  various  "plug-in"  modules  are  added.  The  data  representation 

features  of  a DMS  enter  as  parameters  for  the  second  stage,  while  the 

resource  management  tactics  are  the  parameters  for  the  last  stage.  The 

proposed  model  structure  is  intended  as  a basis  for  DMS  design  experiments. 

Computing  Reviews  category:  4.  6 (Software  Evaluation,  Tests,  and 

Measurement). 
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ON  PERFORMANCE  MODELLING  OF  DATA  BASE  MANAGEMENT  SYSTEMS 


AN  INDUCTIVE  APPROACH 
Allen  Reiter 


1.  INTRODUCTION 

The  modelling  of  comouting  systems  is  hardly  a science 
today;  at  its  best,  it  is  perhaps  nearer  to  a black  art. 
The  difficulties  of  modelling  are  caused  by  the  tremendous 
complexity  of  the  systems  and  the  myriads  of  details  which 
affect  their  performance.  Not  only  is  each  individual 
serially-executing  task  a highly  complex  subsystem  in 
itself,  but  we  must  contend  with  multiple  tasks  concurrently 
competing  for  numerous  resources;  these  resources,  while 
functioning  in  parallel,  are  not  (quite)  mutually 
independent  in  their  operation. 

At  the  heart  of  the  modelling  effort  is  the  desire  to 
obtain  quantitative  information  about  the  effects  of  various 
changes  (e.g.,  in  hardware,  scheduling  algorithms,  data 
organization,  task  load)  on  overall  system  performance.  The 
reason  for  modelling  is  simply  that  actual  experimentation 
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is  prohibitively  exoensive  (if  at  all  feasible)  and  rarely 
employed . 

Analytic  models  which  attemot  to  describe  an  entire 
system  suffer  from  poor  accuracy  because  of  the  very  high 
level  of  abstraction  and  because  of  necessary  but  not  always 
tenable  assumptions  about  the  distribution  in  time  of 
relevant  events.  Such  models  are  perhaps  most  useful  in 
indicating  gross  performance  and  in  studying  the  individual 
behavior  of  various  system  components  while  ignoring  their 
interactions.  The  information  obtained  via  such  models  can 
yield  valuable  insight  when  taken  in  conjunction  with  data 
obtained  via  actual  measurements  or  simulation.  In 
particular,  knowledge  of  the  theoretical  norm  is  vital  if 
departure  from  it  is  to  be  detected  and  the  reason 
understood . 

Discrete-event  simulation  models  have  more  flexibility 
than  analytic  models  in  that  any  amount  of  detail  may  be 
incorporated,  and  model  complexity  is  limited  only  by  the 
resources  available  to  develop  and  run  the  model  [20].  On 
the  other  hand,  environment-dependent  input  distributions 
must  be  supplied  to  the  model;  these  are  often  suspect  in 
how  well  they  reflect  reality.  Also,  the  simulator  is  faced 
with  problems  in  validating  and  calibrating  the  model. 

One  approach  to  modelling  which  has  gained  recent 
popularity  is  trace-driven  simulation.  An  existing 
operational  system  is  instrumented  with  a probe  which 
collects  actual  run-time  data.  These  data  are  abstracted 
and  utilized  to  form  the  input  to  the  model.  The  model  is 
then  parametrized  to  allow  for  changes  in  those  system 
variables  under  study.  We  shall  call  such  models  deductive , 
as  they  are  based  on  _a  posteriori  analysis  of  experimental 
evidence . 
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Among  the  many  advantages  claimed  for  this  aDDroach  are 
credibility,  accuracy,  low-level  resolution,  and  ease  of  use 
[17],  A deductive  model  is  undeniably  useful  in 
"fine-tuning"  a system.  Its  obvious  limitation  is  that  it 
cannot  be  used  to  predict  oerformance  of  a proposed  system; 
i.e.  one  for  which  no  trace  data  are  available. 

Somewhat  less  obviously,  even  in  existing  systems,  the 
decision  on  what  constitutes  an  "event"  for  the  probe 
greatly  influences  the  type  of  changes  which  can  be  studied. 
For  example,  a probe  which  records  all  input-output  activity 
may  be  useless  in  studying  the  effect  of  changes  to  the 
underlying  data  structures  (such  as  changing  from  an  indexed 
sequential  to  a hash-coded  directory) ; in  this  case  the 
probe  is  at  too  low  a level.  Moreover,  many  high-level 
"events"  are  often  hidden  in  the  processing  logic  of  a 
program  and  cannot  be  detected  by  conventional  monitoring 
techniques . 

This  paper  is  concerned  with  inductive  modelling.  In 
this  approach  a model  of  a computer  system  is  synthesized 
from  basic  building  blocks.  These  blocks  determine  the 
level  of  abstraction  of  the  model.  Building  such  a model  is 
a process  not  unlike  constructing  an  actual  computing 
complex  with  its  operating  system  and  then  writing  an 
application  program  for  each  element  in  the  job  mix.  To 
keep  the  task  at  a manageable  level,  much  of  the  detail 
clearly  needs  to  be  suppressed.  Before  we  can  describe  this 
task,  we  must  narrow  our  universe  of  discourse  and  establish 
a point  of  view. 

We  restrict  our  attention  to  data  base  management 
systems,  i.e.  computer  systems  whose  primary  function  is 
manipulating  large  amounts  of  data.  In  addition  to  a 
conventional  operating  system,  several  layers  of  generalized 
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data  management  software  (DMS)  may  be  present;  we  shall  in 
part  be  concerned  with  analysis  of  some  basic  DMS  components 
so  that  we  can  synthesize  different  types  of  architectures 
of  DMS's  in  the  model.  One  simplifying  assumption  is  that 
such  systems  are  I/O-bound,  i.e.  the  central-processor 
usage  character istics  of  the  job  mix  do  not  have  significant 
impact  on  performance.  While  we  do  not  ignore  the  CPU 
entirely,  we  do  not  propose  to  equip  the  model  with  tools 
which  facilitate  CPU-usage  representation.  On  the  other 
hand,  we  do  desire  careful  description  of  features  which 
directly  impact  the  I/O  characteristics  of  the  tasks. 

There  are  various  aspects  of  a DMS.  It  incorporates  a 
view  of  information  structures,  imposing  this  view  on  the 
user  who  wishes  to  access  the  data.  The  DMS  may  have 
built-in  mechanisms  by  which  the  data  are  accessed;  the  user 
must  specify  processes  over  his  data  in  those  terms.  {*} 
Since  the  DMS  must  ultimately  execute  on  a real  machine,  it 
also  provides  a mapping  from  its  information  structures  onto 
physical  storage  structures.  Finally,  the  DMS  must  have 
algorithms  for  executing  processes  over  the  real  structures 
corresponding  to  the  conceptual  processes  over  the  logical 
structures,  and  also  for  allocating  and  sharing  resources  in 
a time-shared  environment.  Each  of  these  aspects  is 
relevant  to  our  task. 

Our  basic  point  of  view  is  that  the  model  shall  be  used 
for  experimenting  with  DMS  and  application  design.  It 
should  enable  a system  designer  to  evaluate  the  performance 


{*}  This  is  termed  a lack  of  data  independence  in  the 
programs. 
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implications  of  various  design  tradeoffs  under  various  usage 
assumotions,  or  to  make  a comparative  evaluation  of 
different  DMS ' s in  the  general  context  of  an  application. 
Typically,  a prospective  customer  for  a DMS  knows  the 
expected  usage  only  approximately;  moreover,  the  usage  is 
likely  to  be  changing  with  time.  Relative  performance 
figures  may  be  just  as  valuable  as  absolute  ones.  Thus  the 
usefulness  of  the  model  does  not  hinge  on  the  accuracy  of 
the  usage  assumotions.  At  the  same  time,  if  the  actual 
system  is  suitably  instrumented  and  collects  appropriate 
statistics,  it  should  be  possible  to  feed  them  to  the  model 
for  fine-tuning  the  operation. 

The  general  layout  of  an  inductive  model,  showing  three 
stages  of  the  modelling  process,  is  shown  in  Figure  1. 

The  first  stage  translates  a user-supplied  task 
description  specified  at  a high  conceptual  level  into  an 
intermediate-level  system  representation.  The  user  task 
description  is  in  terms  of  the  logical  data  view  of  some 
particular  DMS  (relational,  network,  hierarchical,  or 
other).  The  system  task  description  (in  Standard 
Intermediate  Data  Base  Language  - SIDBL)  is  in  a standard 
form  and  includes  a concrete  representation  for  each  access 
path  employed  by  this  particular  DMS.  Data  however  are 
still  addressed  at  a logical  level;  no  reference  is  made  to 
any  physical  attributes  of  the  data  items  or  of  the  storage 
representations  employed  by  the  DMS  implementation.  The 
translator  is  dependent  on  the  particular  DMS  in  question, 
and  may  be  similar  in  structure  to  the  translator  used  in 
implementing  the  actual  system. 

The  second  stage  involves  modelling  the  data  storage 
representation.  The  logical  data  elements  are  mapped  onto 
blocks  of  secondarv  storage,  and  on  this  basis  the  data 
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Figure  1.  An  inductive  simulation  model,  in  3 stages. 
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mani.Dulati.on  ooerations  of  S1DBL  are  translated  into  a 
block-oriented  instruction  stream.  These  instructions  are 
in  terms  of  a virtual  data  machine  (VDM) ; questions  dealing 
with  dynamic  resource  allocation  as  well  as  some  other 
issues  (system  configuration,  file  extents,  etc.)  are 
postooned  until  the  final  stage.  The  representation 
modeller  consists  of  data  descriotion  mechanisms  and  a 
generalized  translation  algorithm  independent  of  soecific 
DMS's.  In  addition,  it  must  be  provided  with  various 
(small)  "olug-in"  modules  which  characterize  the  storage 
representation  features  used  by  each  specific  DMS . When 
these  are  added,  the  generalized  framework  becomes  a 
representation  model  for  this  particular  DMS. 

The  output  of  the  first  two  modelling  stages  is  a 
synthesized  job  description  in  terms  of  low-level  events. 
One  can  conceive  of  existing  DMS's  being  instrumented  for 
informing  a monitor  when  such  events  occur;  a trace  of  a 
program  execution  collected  by  the  monitor  would  resemble 
the  event  stream  generated  by  our  representation  modeller 
and  would  play  the  same  role  for  the  next  stage. 


The  third  stage,  the  execution  modeller  EXM, 
incorporates  all  of  the  system  dynamics.  EXM  is  a model  of 
a multiprogr ammed  operating  system,  resembling  somewhat  such 
commercially-available  packages  as  SAM  (1).  EXM  is, 
however,  parametrized  for  various  choices  of  resource 
management  strategies  (relevant  to  DMS  performance) , and  it 
is  intended  for  a wide  class  of  operating  system  and 
hardware  architectures.  EXM  is  not  explicitly  concerned 
with  data  representations,  but  is  used  to  translate  the 
process  model  obtained  in  Stage  2 into  performance  figures 
for  a given  system  architecture  and  job  mix.  Again,  for  a 
fixed  choice  of  strategies  our  generalized  framework  becomes 
an  execution  model  for  one  Particular  DMS. 
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Storaqe  representation  differences  among  DMS ' s may 
result  in  different  event  streams  for  the  same  user  orocess. 
Differences  in  resource  management  tactics,  job  mix,  and 
configuration,  result  in  different  execution  statistics  for 
a given  set  of  event  streams.  The  VDM  thus  provides  a 
convenient  interface  for  separating  the  static  from  the 
dynamic  issues.  Moreover,  storage  representation  modelling 
is  often  subject  to  stochastic  variability,  as  the 
reoresentation  in  storage  of  a particular  data  base  is 
usually  not  deterministic  but  may  vary  depending  on 
insertion  sequence,  deletion  history,  etc.  In  studying 
issues  which  impact  on  the  system  dynamics,  it  is  useful  to 
be  able  to  insulate  the  results  from  the  effects  of  random 
changes  in  storage  representation.  This  we  are  able  to  do 
by  first  generating  a (fixed)  set  of  VDM  streams  and  then 
using  these  for  various  experiments  with  system  dynamics. 

The  problem  of  modelling  data  representations  at  a 
level  suitable  for  microscopic  modelling  was  also  addressed 
by  Senko  et  al  (114],  [15]).  Senko  proposes  a four-tiered 
approach.  At  the  highest  level,  a user's  view  of  processes 
and  data  is  expressed  in  a non-procedural  language  (FORAL) . 
This  is  translated  into  an  access-path  view  which 
corresponds  to  the  input  to  our  stage  2:  data  are 
represented  as  strings  and  processes  are  described  in  a 
procedural  language  which  closely  resembles  SIDBL.  At  the 
third  (encoding)  level,  strings  are  assigned  concrete 
physical  attributes  and  mapped  onto  contiguous  virtual 
storage  units  called  basic  encoding  units  (BEU’s).  Finally, 
at  the  Physical  device  level,  the  BEU's  are  mapped  onto 
actual  storage  devices.  Sibley  [18]  uses  a similar  model  in 
discussing  the  issue  of  data  transferability.  A somewhat 
similar  four-level  architecture  is  proposed  in  [13]  for 
implementing  a relational  DMS. 
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Our  aporoach  differs  from  Senko’s  in  a number  of 
significant  ways.  First,  we  are  concerned  with  developing 
general  mechanisms  which  are  used  for  modelling  the  dynamics 
of  DMS  execution,  not  only  with  description  mechanisms  for 
the  static  aspects  of  the  data  representations.  {*}  Thus, 
e.g.  in  modelling  a B-tree  "insert"  operation  ([8])  which 
causes  a block  to  split,  it  is  not  sufficient  for  us  to  have 
a representation  of  the  "before"  and  "after"  states  of  the 
data  base;  we  want  to  be  able  to  describe  the  intermediate 
steps  in  the  splitting  algorithm  of  a particular 
implementation  of  B-trees.  Second,  Senko  views  directory 
decoding  as  a low-level  function  related  to  physical  device 
"access  methods";  we  view  it  as  a high-level  function  and 
model  directories  using  the  same  mechanisms  as  for  other 
higher-level  data  structures.  This  enables  us  to  take  a 
more  uniform  view  of  physical  access  which  is  independent  of 
the  underlying  hardware  or  DMS  implementation.  We  can  for 
example  obtain  static  descriptions  of  the  block  reference 
patterns  for  the  same  process  using  each  of  ISAM  ([6]),  SIS 
([3])  and  H1SAM  ([7])  organizations,  whereas  for  Senko  these 
differences  would  appear  only  in  the  execution  statistics. 
Our  representation  modeller  maos  data  onto  physical  blocks, 
which,  while  not  having  yet  been  assigned  a specific 
location  in  secondary  storage,  nevertheless  correspond  to 
units  of  physical  storage  and  will  each  eventually  be  the 
subject  of  a single  well-defined  I/O  operation  (not  an 
"access  method").  Our  block  is  therefore  at  a considerably 
lower  level  than  Senko’s  BEU,  being  in  fact  a primitive 


{*}  Although  Senko’s  earlier  FOREM  system  (16]  included 
the  simulation  of  disk  accesses,  the  mechanisms  were  largely 
ad  hoc. 
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concept  uniformly  defined  for  all  DMS's.  Finally,  our  VDM 
is  equipDed  with  a procedural  language;  no  counterpart  is 
described  by  Senko  for  the  encoding  or  physical  device 
levels.  This  is  because  Senko's  orientation  at  the  lowest 
modelling  level  is  directed  toward  the  hardware;  our  VDM  is 
an  operating-system-level  interface  which  enables  us  to 
study  (among  other  things)  the  effects  of  a multiprogramming 
resource-sharing  environment. 

This  paper  does  not  deal  with  translation  into  a S1QBL 
representation;  this  issue  will  be  addressed  in  future  work. 
However,  a data  description  language  which,  with  some 
modifications,  may  be  a suitable  "front  end"  for  our  model, 
is  described  in  [19].  We  sketch  in  successive  sections 
SIDBL , VDM,  and  the  representation  and  execution  modellers. 
The  descriptions  are  not  meant  to  be  exhaustive;  indeed,  any 
such  system  must  be  open-ended  at  all  levels  in  order  to  be 
able  to  accomodate  new  developments  in  data  base  technology. 
The  author  first  dealt  with  the  problem  of  modelling  data 
representations  in  [9] ; the  present  work  contains  a 
substantial  revision  of  that  material. 

A simulation  model  which  utilizes  the  general  framework 
discussed  here  is  currently  operational.  It  is  written  in 
FORTRAN  IV  (which  is  the  host  language  for  SIDBL) . It  is 
being  used  to  conduct  experiments  in  DMS  design;  some 
results  have  been  described  in  [10]  and  [11]. 

2.  SIDBL  - A DATA  BASE  LANGUAGE 

2.1  Storage  oaths  and  access  oaths. 

Before  describing  SIDBL,  we  must  establish  the 
distinction  between  storage  and  access  oaths  for  items  in  a 
data  base.  For  our  purposes  we  consider  a sinqle-level 
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(Dossibly  virtual)  secondary  store,  and  assume  that 
redundancy  is  not  utilized,  i.e.  an  item  appears  in  storage 
exactly  once. 

A storage  path  determines  where  in  storage  the  item  is 
to  be  placed.  The  Placement  of  some  items  in  storage  is 
arbitrary;  for  others,  depending  on  the  DMS,  hierarchical 
relationships  may  be  utilized  when  Placing  occurences  of 
various  items  in  proximity  to  one  another.  Thus,  a file  may 
"contain"  records,  a repeating  group  - instances  of 
occurences,  a composite  field  - subfields,  etc.  Since  there 
is  exactly  one  storage  path  for  each  item,  relationships 
more  complex  than  a tree  are  rarely  utilized  in  a storage 
strategy,  and  are  not  considered  here. 

An  access  path  corresponds  to  a particular  way  of 
processing  collections  of  data  items,  and  (for  many  DMS’s) 
there  may  be  several  different  access  paths  to  an  item.  An 
access  path  may  coincide  with  a storage  path;  indeed,  the 
storage  path  may  have  been  chosen  in  order  to  optimize 
performance  along  this  access  oath  (presumably,  because  this 
access  path  is  used  very  frequently.) 

When  an  item  is  accessed  in  a real  data  base,  many  of 
the  structural  parameters  associated  with  the  item  (e.g. 
the  number  of  its  storage  oath  neighbors  in  the  same  block) 
are  implicitly  available.  This  is  true  regardless  of  the 
access  path  used  in  reaching  the  atom.  In  our  model, 
however,  these  parameters  are  obtained  iteratively  when 
traversing  a storage  path  (the  algorithms  for  this  are 
discussed  in  Section  4)  and  may  not  be  available  via  other 
access  paths.  The  reader  is  asked  to  keeo  in  mind  the 
distinction  between  storage  and  access  paths  in  the  seauel. 
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2.2  View  of  data 


A data  base  is  a collection  of  (instances  of)  atoms  and 
of  (instances  of)  access  connections  among  the  atoms.  Atoms 
and  connections  are  called  the  elements  of  a data  base. 
Examoles  of  atoms  are:  a file;  a record;  a compound  field;  a 
character  string.  While  an  element  usually  contains  data, 
and  therefore  will  eventually  be  assigned  a "length"  and 
other  ohysical  attributes,  it  is  oossible  to  have  atoms  or 
connections  which  serve  a conceptual  function  only  and  have 
no  physical  manifestation. 

A connection  from  atoml  to  atom2  connotes  an  ordered 
processing  relationship  among  them,  allowing  access  to  atom2 
immediately  after  accessing  atoml  without  needing  to  access 
intermediate  atoms.  In  this  sense  atom2  is  addressable  from 
atoml . 


Motivated  by  considerations  in  modelling  storage  paths 
and  by  the  fact  that  all  access  Daths  are  directed,  we  think 
of  connections  as  being  hierarchical:  a connection  is  either 
from  a "father"  to  a "son",  or  from  a "brother"  to  a "next 
brother".  Access  oaths  among  brothers  define  seguences 
(ordered  lists)  of  elements.  Specifically,  we  identify 
three  different  connection  types,  dispensing  with  others  for 
conciseness . 

2.2.1  Successor  connection  for  the  next  element  in  the 
sequence . 

2.2.2  Oldest-son  connection  from  a father  atom("owner" 
of  the  seauence)  to  the  first  element  of  the 
sequence . 
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2.2.3  Keyed-son  connection  from  a father  atom  to  any 
element  of  a sequence.  Such  connections  always 
imply  a system  of  directories,  discussed  in 
section  4.  The  directory  is  transparent  at  the 
SIDBL  command  level. 

Note  the  distinction  between  oldest-son  and  keyed-son 
connections.  If  the  elements  of  a seouence  are  not  keyed, 
the  second  and  subsequent  elements  are  not  connected  (along 
this  path)  to  the  father;  the  second  element  can  be  reached 
from  the  father  only  by  reaching  the  first  element  of  the 
seouence,  etc. 

Access  path  connections  other  than  along  storage  paths 
always  utilize  pointers.  The  oointer  itself  is  a 

pseudo-element  of  the  data  base;  it  occupies  soace  and  must 
be  ohysically  accessed  before  the  access  from  atoml  to  atom2 
can  take  place,  but  is  transparent  to  the  SIDBL  user.  The 
access  from  atoml  to  the  pointer  is  always  along  a storage 
path.  For  DMS ' s which  utilize  simple  structures  such  as 
linked  lists  for  access  path  representation  (e.g.  IDMS  [4]) 
access  to  the  pointer  is  trivial,  as  it  is  necessarily  in 
the  same  block  as  atoml.  For  other  DMS's  (e.g.  if  pointer 

arrays,  a type  of  directory,  are  used  for  access  path 

representation)  access  to  the  Dointer  may  involve 

significant  work  on  the  oart  of  the  system.  We  stress 
however  that  this  is  transparent  for  SIDBL  commands;  access 
is  directly  from  atoml  to  atom2.  Storage-path  connections 
are  called  local ; others  are  called  global . 

2.3  Data  descriotion. 

A data  base  schema  specifies  the  element  (and 
pseudo-element)  types  and  the  hierarchical  storage  and 
access  oath  relationships  among  them.  Each  atom  type 
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appears  as  a uniquely  named  item  description  node  (IDE).  If 
there  is  a father-son  connection  from  some  occurence  of  this 
atom  to  a sequence  of  other  atoms,  this  is  reflected  in  the 
schema  by  a link  from  this  IDE  to  the  IDE  for  the  first 
element  of  the  sequence,  with  an  indication  of  whether  the 
connection  is  local  or  global;  the  brothers  are  similarly 
linked. 

In  addition  to  the  access  Dath  connections,  each  IDE 
contains  user-specified  values  for  attributes  relevant  to 
the  modelling  process.  These  are  discussed  in  Section  4.5. 

2.4  Operations. 

SIDBL  is  a simDle  node-at-a-time  navigational  language 
similar  to  CODASYL's  DML[2]  and  DIAM's  RDL[14).  Processing 
is  represented  as  a sequence  of  operations  on  trees.  We 
traverse  a tree,  inspecting,  adding,  changing,  or  deleting 
nodes.  A CPU  clock  may  also  be  advanced  between  SIDBL 
commands  to  take  care  of  processing  not  otherwise 
represented  in  the  model. 

A process  has  an  arbitrary  number  of  (named)  stacks 
associated  with  its  execution.  A stack  can  be  considered  to 
be  a data  base  variable  which  takes,  as  values,  pointers  to 
a current  data  base  location  and  its  antecedents  in  a tree. 
(It  contains  values  of  attributes  associated  with  these 
nodes.)  Stacks  olay  the  same  role  as  'currency  indicators' 
in  DML;  they  are  however  explicitly  specified  as  arguments 
by  SIDBL  commands. 

The  following  SIDBL  commands  are  currently  implemented. 

STINIT (atomtype ) - sets  up  a new  stack  and  points  it  to 
(an  occurence  of)  the  specified  atom  in  the  data  base. 
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LOCATE  DOWN  (<sectuence  number  of  elements  or  RANDOM) 
"executes"  a father-son  connection.  From  the  current  father 
atom  occurence  we  access  the  oldest  son  occurence  and  then  a 
succession  of  next  brothers,  until  the  soecified  atom  is 
reached.  If  the  sons  are  keyed,  we  do  not  traverse  the 
seauence;  instead,  a directory  is  decoded.  The  newly 
accessed  atom  becomes  current.  Optionally,  the  atom 
orecedinq  the  indicated  atom  in  the  access  path  (which  may 
be  the  father  atom,  in  case  the  indicated  atom  is  the  oldest 
son)  is  accessed.  This  mode  is  usually  followed  bv  a MODIFY 
command  and  is  used  for  example  in  addinq  or  removinq  an 
element  to/from  a linked  list. 

LOCATE  NEXT  accesses  the  next  brother  occurence. 

LOCATE  SAME  accesses  (aqain)  the  current  atom 
occurence . 


LOCATE  UP  accesses  the  father  atom  in  this  access  path. 

INSERT  SEQUENTIALLY  (DOWN  or  NEXT)  creates  a new 
occurence  of  the  tarqet  atom.  This  command  has  the 
implication  that  the  new  atom  is  beinq  created 
"sequentially",  for  instance  durinq  initial  creation  of  a 
data  base. 

INSERT  RANDOMLY  (DOWN  or  NEXT)  creates  a new  occurence 
of  the  tarqet  atom,  and  models  its  insertion  into  an 
existinq  data  base. 


DELETE  removes  the  current  atom  from  the  data  base. 

MODIFY  chanqes  the  content  (but  not  the  structural 
attributes)  of  the  current  atom  in  the  data  base. 
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LOCK/UNLOCK  orevents/al lows  access  by  other 
simultaneous  orocesses  to  the  current  block  or  current  area. 
(More  elaborate  access  control  mechanisms  require  an 
extension  of  our  model.) 

OPEN/CLOSE  invoke  models  of  the  cor resDond ing  run-time 
system  routines  for  this  area. 

STEND  erases  the  current  stack. 

Some  commands  (e.g.  INSERT  and  DELETE)  are  allowed 
only  if  the  node  was  reached  via  a storage  oath,  as  we 
otherwise  lack  the  storage-structure  attribute  values 
required  by  the  modelling  process.  SIDBL  requires  that  the 
user  explicitly  establish  a storage  path  even  when  the 
modelled  system  has  no  similar  requirement.  {*}  We 
therefore  provide  for  a parameter  CONTROL  implicit  for  SIDBL 
traversal  commands:  when  CONTROL=ON,  the  parameter  values 
reauired  by  the  modelling  process  are  generated,  but  the 
corresponding  VDM  commands  which  would  otherwise  be 
generated  bv  the  translator  are  supressed. 

Higher-order  operations  are  represented  as  short 
subroutines  using  the  above  commands.  One  such  subroutine 
is  TRAV,  which  visits  every  local  descendant  of  the  current 
atom  in  preorder  (with  exits  for  possible  additional 
processing  when  we  enter  and  leave  a node.)  TRAV  is  entirely 


{*}  Explicit  storage  paths  mav  need  to  be  established  in 
other  contexts.  In  IDMS,  when  modelling  the  FIND  OWNER  OF 
SET  command,  a storage  oath  to  the  owner  must  be  specified 
if  the  set  member  was  reached  via  a different  oath. 
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schema-driven.  To  model  the  sequential  traversal  of  a file, 
we  execute  the  seauence  OPEN  - TRAV  - CLOSE;  to  model  random 
access  of  one  record  and  examination  of  its  contents  we 
execute  the  sequence  LOCATE  DOWN  RANDOM  - TRAV.  Note  that 
this  very  qross  view  of  sequential  and  random  processing  is 
often  sufficiently  accurate  when  investigating  the  effects 
of  changes  in  data  structures,  scheduling  algorithms,  or 
configuration  on  performance.  In  modelling  IDMS, 
subroutines  for  such  functions  as  FIND  PRIOR  RECORD  IN  SET 
execute  the  required  SIDBL  commands  depending  on  the 
presence  of  "orior"  and  "owner"  pointers  for  the  set.  For 
this  ouroose,  additional  DMS-deoendent  information  may  be 
included  in  the  data  description;  in  the  case  of  IDMS,  two 
additional  flags  were  required.  Similar  subroutines  can  be 
written  to  model  set  intersection  and  union  operations  on 
pointer  arrays  or  to  model  a file  sort. 

3.  THE  VIRTUAL  DATA  MACHINE  VDM 

3.1  The  need  for  a "virtual"  machine. 

The  VDM  provides  a means  for  process  specification  one 
level  below  that  provided  by  SIDBL.  It  incorporates  the 
data  representation  features  specified  by  the  user  and/or 
inherent  in  the  DMS. 

We  can  think  of  two  oeoole  cooperating  in  runninq  an 
installation:  a data  manager,  responsible  for  selecting 
software  and  determining  the  data  structure  design,  but 
knowing  little  about  resource  management;  and  a system 
manaqer,  responsible  for  configuring  and  fine-tuning  the 
system  and  for  schedulinq  the  execution  of  various 
processes,  but  not  knowledqeable  about  data  management.  The 
former  communicates  with  the  latter  by  describing  each 
process  as  a VDM  command  stream. 
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Oependinq  on  the  level  of  sophistication  of  the 
resource-management  strategy,  the  VDM  process  description 
may  be  too  elaborate.  In  this  case  we  will  be  expending 
unnecessary  overhead  first  in  generating  the  description  and 
then  while  simulating  process  execution.  Thus,  we  allow  for 
the  oossibilitv  of  elaborate  buf fer-manaqement  strategies 
and  for  the  sharing  of  data  amonq  concurrent  (independent) 
processes;  when  modelling  a DMS  which  does  not  employ  such 
tactics,  a simpler  process  description  might  have  sufficed. 
On  the  other  hand,  having  generated  such  descriptions  we  are 
able  to  investigate  the  potential  payoffs  in  introducing 
changes  into  the  DMS  resource  management  tactics. 

A VDM-level  process  description  can  provide  some 
insight  into  the  amount  of  work  required  by  a process.  Two 
different  data  organizations  (e.g.  with  and  without  "owner" 
pointers  for  some  IDMS  sets)  will  in  general  result  in 
different  VDM  descriptions,  even  when  the  user's  view  of  the 
process  is  the  same.  The  VDM  descriptions  can  be  compared 
qualitatively,  for  example  by  counting  the  number  of 
different  blocks  accessed  by  each  one.  However,  the  main 
function  of  a VDM  process  description  is  to  form  the  input 
to  the  final  modelling  stage,  the  execution  modeller. 

3.2  View  of  data. 

A block  is  the  basic  unit  of  data  storage  and  the  unit 
for  inout/outout  operations.  It  is  accessed  by  a single 
Primitive  I/O  action  via  a unique  address  (translated  by  EXM 
into  a unit-oriented  address  via  extents  tables.) 


To  make  the  concept  of  "I 
underlying  hardware  architectu 
rotating  secondary  memories 
arm-oositioninq  maneuver,  at 


/0  action"  independent  of  the 
re  we  adoot  the  convention  for 
that  an  action  consists  of  an 
most  one  revolution  to 
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accomDlish  rotational  positioning,  and  the  actual  data 
transfer.  Thus,  in  ISAM,  where  the  track  index  must  be  read 
in  order  to  find  the  block,  the  'READ'  operation  comprises 
two  or  more  distinct  actions  even  though  the  work  is 
accomplished  within  the  hardware  and  channel  logic. 

At  the  VDM  level  commands  are  not  explicitly  concerned 
with  I/O.  However,  the  object  of  each  command  is  a block. 
At  this  level  it  is  convenient  to  treat  the  address  as  a 
three-dimensional  entity  consisting  of  "area"  of  physical 
storage,  "tyoe”  (logical  subdivision  of  a file)(M,  and 
"sequence  number". 

3.3  VDM  commands. 

The  argument  for  each  of  the  following  is  a block 
address. 

3.3.1  FETCH  is  the  basic  data  addressing  operation:  it 
causes  the  block  to  be  positioned  for  processing  in  core. 
FETCH  is  executed  every  time  a process  needs  a data  item 
within  a block.  We  do  not  rely  on  a previous  FETCH  for  the 
same  block,  since  EXM  allows  for  various  buffer  replacement 
strategies,  some  of  which  may  cause  an  active  block  to  be 
overlaid. 

3.3.2  RELEASE  signals  to  core  management  routines  that  the 
task  has  no  further  need  of  the  current  block.  The 


{*}  For  an  example  of  usinq  "type"  in  the  context  of 
storage  management  tactics,  see  (11].  See  also  3.3.9 
below. 
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semantics  of  the  ooeration  deoend  on  the  allocation  strategy 
used.  From  the  Doint  of  view  of  the  task,  this  means  that 
the  block  is  no  longer  "active”  and  (if  its  contents  have 
been  modified)  should  be  recorded  in  secondary  storage  at 
the  convenience  of  the  system. 

3.3.3  STORE  requests  that  the  block  be  recorded  in  secondary 
storage  immediately. 

3.3.4  PREFETCH  requests  the  system  to  attempt  scheduling 
input  of  one  or  more  blocks  beyond  that  block  currently 
being  processed.  This  is  usually  used  when  modelling 
sequential  processing  of  a chain  (see  4.2).  Only  the  "area" 
and  "tyoe"  components  of  the  address  are  significant; 
prefetch  modelling  is  accomplished  by  a scan-ahead  of  the 
instruction  stream. 

3.3.5  ALLOCATE  is  a request  for  a core  buffer  prior  to 
creating  a new  block. 

3.3.6  ALBLOCK  is  a request  for  the  allocation  of  a block  of 
secondary  storage. 

3.3.7  FREE  informs  the  disk  space  management  routine  that 
the  block  is  no  longer  needed. 

3.3.8  MODIFY  is  identical  with  FETCH  exceot  that  the  buffer 
is  marked  as  modified  and  will  eventually  need  recording  in 
secondary  storage. 

3.3.9  LOCK/UNLOCK  orevents/permits  access  to  all  or  part  of 
an  area  by  concurrent  processes.  If  "sequence  number”  is 
null,  all  blocks  of  this  type  are  intended;  if  "tyoe"  is 
also  null,  the  entire  area  is  intended. 
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THE  DATA  REPRESENTATION  MODELLER 


■ 


4.1  Reor esentations  and  models. 


Elements  of  a data  base  have  various  attributes 
associated  with  them.  A reoresentation  of  a data  base  is 
the  assignment  of  values  to  the  attributes  of  each  element. 
A reoresentation  modeller  is  an  algorithm  which  can 
enumerate  the  elements  of  a data  base  and  their  attribute 
values.  In  this  section  we  describe  one  such  modeller. 

Instead  of  enumerating  the  entire  data  base,  our 
modeller  ODerates  iteratively:  when  going  from  element  A to 
element  B,  an  environment  for  B (i.e.  various  attribute 
values)  is  created.  One  of  the  aoals  of  the  modeller  is  to 
determine  when  B is  in  the  same  block  as  A;  for  local 
connections,  we  assume  that  B would  have  been  placed  into 
the  same  block  as  A provided  that  there  was  enough  room  to 
do  so.  Many  of  the  attributes  are  used  in  making  the 
determination  of  "required"  and  "available"  space  for  B. 
The  modelling  algorithm  makes  use  of  the 
previously-established  environment  of  A to  obtain  B's 
environment.  Little  memory  is  utilized:  if  B is  a son  of  A, 
A's  environment  is  preserved  in  the  stack;  if  B is  a brother 
of  A,  B's  environment  replaces  A's;  if  B is  the  father  of  A, 
then  we  return  to  B's  environment  (which  had  been  saved  in 
the  stack),  discarding  the  one  for  A. 


Before  sketching  the  modelling  algorithm,  we  must 
introduce  some  auxiliary  data  structures  basic  to  the 
mapping  from  the  logical  constructs  of  SIDBL  onto  the 
block-oriented  constructs  of  VDM.  These  enable  us  to 
describe  representational  features  of  specific  DMS's 
conveniently  within  a general  framework. 
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4.2  Data  structures 


A chain  is  an  ordered  sequence  of  blocks.  The  blocks 
mav  be  ohysicallv  adjacent  in  storage,  or  exDlicit  chain 
Dointers  mav  be  Dresent.  The  significance  of  the  chain 
orderinq  is  usually  related  to  the  conceDt  of  "seauential 
orocessinq”  (and  oossiblv  to  the  storage  allocation 
ohilosoohv)  of  the  DMS.  Pointers  to  other  blocks  may  also 
be  oresent  associated  with  some  of  the  the  data  elements 
within  the  chain,  but  these  are  d istinauished  from  the  chain 
oointers. 

A cluster  is  oart  (or  all)  of  a sequence  of  brothers 
contained  in  one  block. 


A sequence  of  brothers  reoresented  as  a chain  of 
clusters  is  orooer  if  the  chain  ordering  is  consistent  with 
the  orderinq  of  the  sequence.  In  Figure  2,  the  sequence  in 
(a)  is  orooer,  the  one  in  (b)  is  not.  We  assume  that  all 
sequence  reoresentations  in  the  modelled  system  are  orooer. 


We  also 
contains  a 
sequence  can 
oointers.  b 
aooears  is 


assume  that  a orooer  sequence  r eoresentation 
cluster  B from  which  every  other  cluster  of  the 
be  reached  by  a sequence  of  chain  connectors  or 
is  the  initial  cluster ; the  chain  in  which  3 
called  the  main  chain ; every  cluster  not  in  the 


(a)  (b) 


Figure  2. 
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main  chain  is  called  an  offshoot.  In  Figure  3,  81  and  B4 

form  the  main  chain  (81  beinq  the  initial  cluster),  while 
82,  83,  and  85  are  offshoots.  Intuitively,  B1  and  B4  were 
allocated  for  the  seouence  from  a crime  storaqe  area,  while 
82,  «3,  and  85  were  added  later  as  a result  of  the  insertion 
of  additional  seouence  elements,  ol  and  o2  are  oointers  to 
the  offshoot  clusters.  Thev  are  oseudo-elements ; they  do 
not  exist  From  the  user's  Doint  of  view,  but  can 

conveniently  be  treated  as  elements  bv  the  modellinq  system. 

A subset  of  a seauence  consisting  of  consecutive 

elements  is  called  a seauence  segment. 

~ ————— 

A directory  is  a data  structure  for  reoresenting 
connections  from  atom  A to  each  element  of  a seauence  of 
keved  sons  of  A.  It  consists  of  a tree  of  Drooer  sequence 
segments,  the  root  being  in  the  same  block  as  A,  with  the 
following  oroDerties: 
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(a)  *t  each  level,  all  of  the  elements  are  brothers, 
i.e.  the  secruences  are  seaments  of  one  (lonq) 
seauence . 

(b)  At  each  level  but  the  lowest,  the  elements 

(actually  oseudo-elements)  are  each  Dointers  to 
initial  clusters  of  distinct  seouences  at  the  next 
lower  level; 

(c)  At  the  lowest  level,  the  elements  are  the  sons  of 
A; 

A directory  normally  has  at  least  two  levels,  including 
the  root. 

Figure  4 shows  a directory  with  three  levels, 

(all , al2 , . . ,b23 } are  a seauence  of  keved  sons  of  A.  {a,b} 
and  {al , . . . a 5 , bl , b2 } are  two  seouences  of  oseudo-elements 
(directory  indices  at  two  levels).  Althouqh  not  shown,  we 
do  not  exclude  the  oossibilitv  of  offshoots  aooearinq  at  any 
level  of  the  tree. 

4.3  Reoresentation  of  connections. 

A qlobal  connection  from  A to  B is  always  reoresented 
bv  a oointer.  If  the  connection  is  local,  there  are  various 
Dossibi 1 ities ; 

(a)  A and  B are  in  the  same  block  ( contiguous) ; 

(b)  R is  in  the  next  block  of  the  same  chain; 

(c)  B is  in  an  offshoot,  the  oointer  to  which  is 
contiguous  with  A (in  orinciole,  this  may  be 
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a21  a22*,,a51  a52  b11  b12  b21  b22  b23 


Figure  4.  a directory  with  three  levels. 


iterated:  the  oointer  to  the  offshoot  may  itself  be 
in  an  offshoot,  etc.); 

(d)  If  B is  a keyed  son  of  A,  there  is  a directory 
connection  B to  A.  To  qo  from  one  level  of  a 
directorv  to  the  next  lower  level,  the  initial 
cluster  of  the  indicated  seauence  segment  is 
accessed  via  a oointer,  and  then  the  segment  is 
traversed  usina  (a) , (b) , and  (c)  as  necessary 
until  the  desired  element  is  reached. 

In  addition,  for  a local  successor  connection,  we  may 
have  a broken  connector: 
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(e)  There  is  no  exolicit  connector  from  A to  B,  but  B 
can  be  reached  via  an  element  encountered  earlier 
in  the  storaqe  oath  to  A.  Such  connectors  arise  in 
directories  and  in  offshoots.  In  Figure  3,  the 
connections  from  a4  to  a5  and  from  a7  to  a8  are  the 
tvoical  cases  for  offshoots.  In  Figure  4,  the 
connections  from  al3  to  a21  and  from  a52  to  bll  are 
the  tvoical  cases  for  directories. 

4.4  Examoles  from  real  systems. 

4.4.1  Directories. 

IS&M  [6],  HISAM  [71  (for  "root  segments"),  and  SIS  [31 
are  examoles  of  similar  directory  organizations;  for  our 
ourooses,  thev  can  be  oartially  characterized  as  follows. 
In  SIS  (which  uses  B-trees  [8]),  all  chains  are  one  cluster 
lonq . ISAM  mav  have  lonqer  (overflow)  chains  at  the  lowest 
level.  In  HISAM,  offshoots  mav  occur  at  the  lowest  level. 
For  ISAM  and  HISAM,  the  number  of  levels  is  user-soecif ied ; 
for  SIS,  it  is  comDUted  deoendinq  on  the  number  of  elements, 
block  size,  and  other  factors.  IDMS  [41  uses  hash-coding 
for  its  CALC  records,  which  for  our  ourooses  can  be  regarded 
as  a two-level  directory;  identifiers  which  hash  to  the  same 
block  (initial  cluster)  give  rise  to  overflow  chains. 

4.4.2  Other  local  connections. 


In  the  storaqe  of  "secondary  segments",  HISAM  uses 
chains  (without  offshoots)  in  a linearization  of  the  tree. 
In  MUMPS  [S],  oldest-son  connections  are  always  reoresented 
by  oointers,  while  next-brother  connections  are  either 
contiquity  or  next-in-chain  connectors.  In  IDMS,  records 
stored  "via"  a set  are  brothers  and  the  set  owner  is  the 
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father;  both  oldest-son  and  next-brother  connections  can  be 
contiquitv  or  next-in-chain,  and  offshoots  mav  occur. 


4.5  Attributes  of  elements. 


Each  element  or  oseudo-element  of  a data  base  has  the 
following  attributes  associated  with  it.  We  qrouo  them  by 
function. 


Grouo  1 — - Attributes  of  the  element  as  the  root  of  a 

tree  or  subtree; 


(a)  Lenqth,  in  bytes; 


(b)  Total  number  of  sons; 


(c)  Total  size  of  the  local  descendant  set  (defined 
recursively  as  the  sum  of  the  lengths  and 

descendant  set  sizes  of  all  sons,  if  the  sons  are 
local ) ; 


I 


(d)  Total  number  of  directory  levels  (if  a directory 
index  element ) . 

Grouo  2 — Attributes  of  the  element  as  a member  of  an 
ordered  sequence; 

(e)  Ordinal  number; 


(f)  Total  size  of  the  local  subsequent  set  (the  sum  of 
the  lenaths  and  the  local  descendant  sets  of  local 
brothers  to  the  right  of  this  element). 


Grouo  3 — Attributes  associated  with  the  block  in 

which  the  element  resides: 
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(a)  ^lock  address; 


maximum  caoacity  (in  bytes); 


1 


(h)  Slock  size,  i.e. 

(i)  Loadino  density,  i.e. 
unused ; 


amount  of  soace  currently 


(i)  Number  of  elements  in  this  cluster, 
oossible  offshoots; 


including 


(k)  Ordinal  number  of  the  element  in  this  cluster. 

Grouo  4 — Attributes  associated  with  the  tactics  for 
olacinq  sons  and  brothers  within  a block; 


(l)  Size  of  local  descendant  set  actually  contained  in 
the  current  block; 

(m)  Size  of  local  subseauent  set  actually  contained  in 
the  current  block. 

The  values  for  attributes  (a)-(c),  (h) , and  (i)  are 
suDolied  bv  the  user  as  oart  of  the  data  descriotion  (see 
2.2).  These  values  may  be  soecified  deterministically  or  as 
Drobabilitv  distributions.  (d)  and  (j)  may  be 
user-soecif ied  or  comouted  by  the  modeller,  deoending  on  the 
DMS . The  others  are  generated  by  the  modeller,  (g) , (1), 
and  (m)  in  a DMS-deoendent  fashion. 

The  attribute  values  for  each  element  and  its  ancestors 
in  the  storaae  oath  describe  the  environment  of  the  element, 
and  are  stored  in  the  stack. 
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4.6  Ooeration  of  the  reoresentation-modellinq  alqorithm. 

To  illustrate  the  ooeration  of  the  alqorithm,  we  sketch 
the  loqic  for  translatinq  the  LOCATE  DOWN  and  LOCATE  NEXT 
commands  (^iqure  5) . In  the  ensuinq  discussion,  the  logic 
is  not  DMS-deoendent  unless  explicitly  so  indicated. 

steos  1,  In,  and  2 are  self-exDlanatorv:  the  element 
attributes  are  qenerated  and/or  uDdated  and  stored  in  the 
stack.  In  translatino  LOCATE  DOWN  to  a keved  son,  we  are 
now  descendioo  to  the  next  level  of  the  directory. 

Steo  3:  The  oldest-son  and  next-brother  connections  may 
be  local  or  olobal  indeoendentlv;  the  connection  tyoe  is 
specified  in  the  schema. 

Steo  4:  We  qet  here  any  time  a new  block  must  be 
accessed,  whether  for  a olobal  connection,  next-in-chain,  or 
for  an  offshoot.  If  an  exDlicit  oointer  is  involved,  the 
orior  (current)  block  must  be  accessed  to  obtain  the 
oointer.  If  the  current  block  is  in  the  same  chain  as  the 
successor,  a RELEASE  command  is  qenerated.  Optionally,  a 
PREFETCH  command  is  also  qenerated. 


Steo  5:  A oluo-in  DMS-deoendent  module  must  be  orovided 
for  the  block  address  determination.  The  module's  identity 
is  specified  via  the  element  descriptor  in  the  schema  and 
mav  varv  from  element  to  element.  For  example,  different 
modules  compute  the  address  for  the  cylinder  index,  track 
index,  and  prime,  cvlinder  and  independent  overflow  areas 
for  ISAM.  The  address  computation  for  an  offshoot  will 
qenerallv  differ  from  that  for  a next-in-chain.  For  a 
qlobal  connection,  a random  address  within  the  area  is 
qenerallv  used. 
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Steo  8; 

If  the  sequence  number 

of 

the 

tarqet 

element 

exceeds 

the 

seauence  number  of 

the 

last 

element  in 

the 

cur  rent 

cluster,  the  next  cluster 

in 

the 

chain 

must 

be 

accessed . 

Steos  7 and  8:  We  have  found  the  block  in  which  the 
element  would  normally  belonq.  We  must  now  determine 
whether  the  element  is  actually  there;  it  may  have  been 
olaced  into  an  offshoot  chain  due  to  overflow.  The 
determination  is  DMS-deoendent,  as  attributes  (1)  and  (m) 
need  to  be  commuted.  For  a svstem  such  as  OSAM.  which 
nlaces  the  entire  descendant  set  before  the  successor  set  in 
a linearization  of  the  tree,  the  comoutation  is 
straiahtforward . For  others  (e.q.  IDMS)  a Drobabilistic 
model  is  used  to  determine  the  division  of  the  remaininq 
soace  amonq  sons  and  brothers. 

Steo  9;  The  tarqet  element  is  in  an  offshoot  chain.  A 
level  is  added  to  the  stack,  and  we  continue  with  steo  4. 
The  number  of  elements  in  the  offshoot  chain  (attribute  (b) 
for  the  oseudo-element)  is  available  as  a byoroduct  of  the 
DMS-deoendent  comoutation  of  steo  7. 

Steo  19 ; We  now  know  where  the  element  is;  a FETCH 
command  is  qenerated.  x Ootionally,  a PREFETCH  command  may 
also  be  qenerated  here. 

Steo  11;  If  we  are  decodinq  a directory  and  have 
reached  an  index  level,  the  orocess  is  reoeated  until  we 
reach  the  lowest  level.  v 

Steos  2n  and  3n  of  NEXT:  If  the  father  node  is  a 

oseudo-element,  we  have  reached  a broken  connector:  the  end 

of  an  offshoot  chain,  or  the  end  of  seciuence  seament  in  a 
directory.  We  ascend  one  level,  and  reoeat  the  orocess. 


''lenerallv,  the  nr pv ious 1 u-cnr rent  block  is  not  the  same  as 
the  block  to  which  we  are  now  returninq;  a RELEASE  command 
for  the  nrevious  block  is  qenerated. 

The  IMREpt  commands  mostly  use  the  same  loqic,  but 
require  several  additional  DMS-deoendent  modules. 
Translation  of  the  other  SIORL  commands  is  stra iqhtforward. 

The  above  looic  is  oriented  toward  the  modellinq  of 
connectors  for  local  connections.  Hence  the  usefulness  of 
our  model  is  directly  related  to  the  extent  to  which  the 
modelled  DMS  utilizes  such  conceDts.  As  an  extreme  case,  we 
mav  consider  a DMS  which  has  no  local  connections.  (Such 
orqanizations , in  which  every  access  oath  is  reoresented  by 
a oointer,  are  sometimes  adooted  for  convenience  of 
imolementation , especially  if  performance  considerations  are 
not  vital.)  In  modellino  this  system  within  our  framework, 
most  of  the  mechanisms  described  above  would  not  be  used. 

4.7  Some  problems  in  modellinq. 

4.7.1  Dependence  on  oast  history. 

In  almost  all  systems,  the  data  representation  at  a 
oiven  moment  is  a function  not  only  of  the  data  content  and 
of  the  hardware-  and  user-specified  parameters,  but  also  of 
the  orocessino  history  of  the  data  base.  Thus,  addinq  a 
record  and  then  deletinq  it  will  qenerallv  not  return  the 
representation  to  its  oriqinal  state.  The  qreater  the 
deqree  of  self-oraanization  in  the  modelled  system,  the  more 
difficult  it  is  to  model. 

To  illustrate  one  problem,  consider  the  followinq 
possible  implementation  of  a tree-handl inq  system  such  as 
MfjMPq  (4).  Data  are  reoresented  in  storaqe  as  binary  trees 
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(left  pointer  to  oldest-soo,  riqht  to  next-brother).  A 
block  alwavs  contains  one  binary  subtree,  with  some  of  the 
branches  oointina  to  descendant  subtrees  in  other  blocks. 
When  a no^e  is  adder I it  is  Placed  in  the  same  block  as  its 
predecessor  (father  or  left  brother).  If  a block  overflows, 
the  subtree  in  it  is  traversed  in  order  to  find  a branch 
(le*"t  or  rioht)  which  most  enuallv  solits  the  subtree  in 
two;  the  half  not  containinq  the  oriqinal  root  is  moved  to  a 
different  block  and  the  cut  branch  is  reolaced  bv  a Dointer 
to  the  new  block. 

A little  reflection  should  convince  the  reader  that 
the  resultinq  structure  for  a larqe  data  base  deoends  on  the 
order  in  which  the  various  nodes  were  added  to  the  system, 
mhe  number  of  oossible  valid  reoresentations  qrows 
combinator iallv  with  the  data  base  size.  Soecif ically  at 
stake  is  the  model  alqorithm  for  comoutinq  the  attributes 
(1)  and  (m)  of  4.5.  The  alqorithm  described  in  [9]  oroduces 
one  oossible  reor esentat ion  which  incoroorates  the  rules  of 
formation;  it  is  not  oarametrized  for  the  data  base  creation 
history.  The  underlvinq  hooe  (based  on  heuristic 
considerations)  is  that  the  oossible  variations  balance  out 
with  resoect  to  oerformance  of  the  orocessinq  oroqrams; 
validation  this  assumotion  aooears  to  be  a difficult  and 
ooorlv  defined  task  reouirinq  a vast  amount  of  exoerimental 
evidence  from  actual  systems. 

4.7.2  Local  memorv  of  the  model. 

Th®  attribute  values  are  comouted  (deterministically  or 
or obabi 1 ist ica l Iv)  based  on  qlobal  data  descriptions, 
however,  data  modification  operations  cause  local  chanqes  in 
these  values.  As  an  example,  an  INSERT  ooeration  chanqes 
the  previously— comouted  "available  soace"  attribute  of  the 
block.  The  model  can  remember  in  the  stack  only  a few  of 
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the  imolied  chances,  an'1  only  for  as  lonq  as  the  block  stavs 
current.  This  limits  the  resolution  oower  of  the  model  for 
a comolex  seouence  of  interrelated  ooerations.  In  general, 
we  exoect  that  an  uodate  task  is  factored  into  a series  of 
"small"  subtasks,  each  of  which  can  be  accurately  modelled 
within  the  memorv  constraints,  and  which  are  mutually 
indeoendent  in  the  sense  that  local  chanqes  in  attribute 
values  need  not  be  remembered  from  one  to  the  next. 

5.  THE  EXECUTION  MODELLER  (RXM) 

EXM  accomolishes  the  bindinq  between  the  static  orocess 
descriotions  and  their  execution  on  a real  machine.  The 
imolementation  is  described  elsewhere  ([12]);  here  we  give  a 
brief  descriotion,  focusinq  on  Dar ametr ization  for  different 
run-time  environments. 

A functional  schematic  of  EXM  is  shown  in  Figure  6.  It 
includes  the  maior  hardware  comoonents  which  affect  DMS 
oerRormance:  orocessors,  I/O  resources  (disks,  channels), 
and  main  storaae  buffers,  and  their  resoective  (software) 
manaqers:  task  scheduler,  I/O  scheduler,  and  storaqe 
allocator.  As  was  the  case  for  the  renresentation  modeller, 
our  aooroach  is  to  orovide  the  qeneral  oroqram  framework  and 
the  descriotion  mechanisms  indeoendentlv  of  the  DMS  being 
modelled,  and  to  auqment  this  bv  DMS-deoendent  "oluq-in" 
modules . 

Task  execution  consists  of  readinq  a VDM  stream  and 
issuinq  the  corresoondinq  command.  Each  block  reference  is 
sent  to  the  "contents  suoervisor"  to  determine  whether  the 
block  is  currently  in  core.  Between  two  successive 
references  by  a task  to  a block,  the  block  might  be 
overwritten.  This  is  the  qeneral  mechanism;  a soecific  DMS 
need  of  course  not  make  use  of  such  tactics.  Similarly,  it 
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Figure  6.  Functional  framework  of  the  EXM. 
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is  oossibl"  tnat.  a block  is  in  core  bv  virtue 
use  bv  this  or  another  task;  if  so  we  "find" 
reouest  is  aenerated.  if  the  reauired  block  is  not  in  core, 
a "read"  command  (which  consists  of  a sectuence  of  ODerations 
for  arm  oositioninq,  rotational  oos itioninq , and  data 
transfer)  is  "executed",  and  task  execution  is  susoended 
until  the  block  is  in  core.  A STORE  command  causes  the 
block  to  be  written,  without  however  necessarily  waiting  for 
the  comoletion  of  the  ooeration.  Other  command  execution  is 
similar;  in  aeneral,  task  execution  is  susoended  if  a 
narticular  resource  which  it  requires  is  not  currently 
available. 

We  now  describe  the  "oluq-in"  modules. 

The  job  scheduler  introduces  work  into  the  system  and 
determines  the  decree  of  multiprogramming.  It  is  called  at 
svstem  initialization  and  at  task  termination;  it  enoueues 
tasks  for  immediate  or  later  startinq. 

The  dispatcher  is  called  bv  the  task  scheduler  whenever 
a processor  resource  is  reauired  for  task  execution  or 
interrupt  processing. 


The  disk  scheduler  is  called  whenever  an  I/O  reauest  is 
to  be  Placed  onto  a device  queue.  The  position  of  the 
reauest  in  the  queue  depends  on  the  scheduling  discipline 
used . 

The  channel  scheduler  is  called  when  a channel  becomes 
free  and  there  are  several  disks  waiting  for  a channel.  It 
determines  which  one  of  the  disks  will  be  serviced  next. 

The  storage  allocator  is  called  to  allocate  one  buffer 
from  a buffer  pool.  Manv  possible  management  strategies  are 
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supported.  buffer  pools  mav  be  associated  with  each  task  or 
shared  amonq  several  concurrent  tasks.  Allocation  oolicies 
mav  overlav  a buffer  which  is  in  active  use.  A oolicv  mav 
take  into  account  huffer  status,  number  of  current  users. 


and 

the  time  the 

contents  were  1 

ast 

referenced , 

all  of 

which 

are 

ma  inta ined 

bu  the  system. 

If 

the  former 

contents 

of  a 

buffer  have  been 

modified,  the  a 

llocator  must 

first 

wr  i te 

the 

block  to  the 

disk. 

The  allocat 

or  is  also  cal 

leH 

for  the  RELEASE  command. 

The 

buffer  is 

identified  bv 

its 

contents 

only. 

The 

semantics  of  the  RELEASE  command  deoend  on  the  allocation 
oolicv  for  the  oool;  there  mav  be  other  concurrent  users  of 
this  buffer,  or  its  contents  mav  already  have  been  overlaid. 


The  Prefetch  scheduler  is  called  for 
command.  Deoendina  on  the  current  state  of 
resources  it  mav  reauest  buffer  allocation  and 
inout  of  one  or  more  blocks  in  advance  of 
location . 


the  PREFETCH 
the  system 
initiate  the 
the  current 


mhe  disk  soace  management  routine  is  called  for  the 
ALPLOCK  and  rreE  commands.  A qarbaqe  collection  module  may 
be  invoked  bv  the  iob  scheduler  when  the  latter  detects 
"slack"  activity. 


OPEN/CLOSE  routines  are  called  via  the  corresponding 

commands . 


These  modules  charac 
strategies.  Hooefullv,  the 
a Particular  system  is  cons 
framework.  In  the  current 
account  for  only  some  1^-1 
is  likely  that  two  quite  di 


terize  a particular  set  of  DMS 
task  of  writing  such  modules  for 
i^erablv  easier  given  the  general 
system,  the  "olug-in"  modules 
5%  of  the  total  FORTRAN  code.  It 
fferent  DMS's  mav  use  similar 
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tactics  in  manaoina  some  resources,  so  that  this  oart  of  the 
model  would  not  need  to  be  rewritten. 

In  addition  to  the  "oluo-in"  modules,  the  hardware 
Darameters  need  to  he  soecified.  The  mechanisms  for  this 
are  auite  conventional  and  are  described  in  [12], 

6.  MODELLING  A GENERAL  NIX 

How  do  we  model  oerformance  in  a mixed  environment, 
i.e.  one  in  which  non-data-base  iobs  are  also  oresent?  We 
attemot  to  qive  a martial  answer  to  this  question.  As  we 
have  not  addressed  the  oroblem  of  modelling  other  tvoes  of 
comoutational  processes,  we  can,  at  best,  hooe  to  obtain 
information  about  the  data  management  oart  of  the  mix.  To 
do  this,  we  need  to  make  some  assumotions  with  regard  to  the 
contention  for  the  same  resources  bv  the  data  base  tasks  and 
other  iobs. 

For  simolicitv,  let  us  assume  that  the  other  jobs 
either  consume  a neqliqible  amount  of  CPU  time  or  else 
ooerate  at  a lower  disoatchinq  oriority  (this  assumotion  is 
often  valid  in  oractice) ; then  there  is  no  interference  to 
the  data  base  tasks  in  CPU  usage.  Also,  we  assume  that  core 
storage  is  Dartitioned  in  a fixed  fashion  between  data-base 
and  other  tasks,  so  that  there  is  no  contention  for  core. 
The  other  source  of  interference  is  in  I/O  activity  on  the 
same  units.  It  may  be  oossible  to  model  this  interference 
bv  representing  the  other  activity  in  terms  of  its  data 
needs,  i.e.  as  a data  bane  task. 

The  most  common  source  of  interference  is  system 
"spooling":  the  use  of  disks  as  buffers  for  orintino.  The 
operation  of  a spooler  can,  for  our  ourooses,  be  modelled  as 
the  sequential  traversal  of  a simolv-structured  file,  using 
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the  tools  already  develooed.  The  size  of  this  file,  and  the 
frequency  of  invocation  of  this  job,  will  contain  built-in 
assumptions  about  the  orint-outout  characteristics  of  the 
mix . 

7.  summary  AND  conclusion 

We  have  attempted  to  sketch  the  total  architecture  of 
an  inductive  data  base  svstem  modeller. 

Task  description  at  an  intermediate  level  is 
accomplished  in  SIDBL.  The  level  is  sufficiently  low  to  be 
free  of  loqical  data  views,  but  is  above 
imolementation-deDendent  considerations.  SIDBL  is  not 
caoable  of  task  description  independently  of  the  DMS  being 
modelled;  in  qeneral  different  DMS’s  will  have  different 
access  oaths  (and  hence  will  Produce  different  SIDBL 
descriptions)  for  a qiven  task  over  the  same  data  base. 
Bowever,  SIDBL  does  provide  a clear  separation  between  the 
task  description  and  DMS  implementation  issues. 

The  maior  contribution  of  this  work  is  in  factoring  DMS 
implementation  issues  into  various  small  modules  and  in 
providing  the  framework  within  which  experiments  can  be 
made.  Two  distinct  models  - static  data  representation  and 
dvnamic  resource  allocation  - are  involved.  Parametr ization 
of  the  former  reauired  defininq  new  data  structures 
appropriate  for  describing  relevant  features  of  DMS 
implementations . 

The  interface  between  the  static  and  dynamic  models  is 
in  terms  of  block-oriented  operations.  It  is  not  clear 
whether  this  restricts  the  scope  of  the  model.  Somewhat 
surprisingly  this  has  not  proven  to  be  a major  handicap  in 
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modellina  ism's  ISAM,  which  in  some  wavs  is  track-  and 
cylinder-  rather  than  block-or iented  in  its  ohilosoohy. 

a microscooic  simulation  model  is  rather  exoensive  to 
run,  and  is  reallv  suitable  for  a very  detailed  look  at 
system  ooeration  within  a narrow  time  window.  {*}  Also,  to 
be  useful  for  data  base  aoolication  desiqn,  a modelling 
system  must  be  eauiooed  with  tools  not  discussed  here,  such 
as  convenient  data  soecif ication  languages.  Nonetheless, 
our  model  in  its  oresent  state  is  Droving  itself  useful  for 
conduction  exoeriments  on  DMS  imolementation  tradeoffs. 
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